-
Notifications
You must be signed in to change notification settings - Fork 13.5k
{aarch64,x86_64}-pc-windows-gnullvm: build host tools #140772
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
r? @marcoieni rustbot has assigned @marcoieni. Use |
This PR changes how LLVM is built. Consider updating src/bootstrap/download-ci-llvm-stamp. |
Forgot to include |
ok, so I guess we need to try this, right? @bors try |
{aarch64,x86_64}-*-windows-gnullvm: build host tools This will require MCP, but I suppose we need to know how long it takes to build first. I opted for bootstrapping from Linux because that's the easiest host system to work with, but once this hits beta, having dedicated Windows runners would be sensible and probably preferable. `--enable-full-tools` for whatever reason doesn't seem to work when cross-compiling, because LLVM tools for the new hosts are not copied into the expected directory. And WiX that bootstrap relies upon to create .msi installers only supports Windows. I haven't tried, but it might be usable via Wine. Almost every commit is self-contained, so let me know if I should split them into separate PRs. try-job: dist-windows-gnullvm
This comment has been minimized.
This comment has been minimized.
maybe you need to add the job to the |
💥 Test timed out |
Oh, right. Totally forgot about it. |
@bors try |
{aarch64,x86_64}-*-windows-gnullvm: build host tools This will require MCP, but I suppose we need to know how long it takes to build first. I opted for bootstrapping from Linux because that's the easiest host system to work with, but once this hits beta, having dedicated Windows runners would be sensible and probably preferable. `--enable-full-tools` for whatever reason doesn't seem to work when cross-compiling, because LLVM tools for the new hosts are not copied into the expected directory. And WiX that bootstrap relies upon to create .msi installers only supports Windows. I haven't tried, but it might be usable via Wine. Almost every commit is self-contained, so let me know if I should split them into separate PRs. try-job: dist-windows-gnullvm
This comment has been minimized.
This comment has been minimized.
💔 Test failed - checks-actions |
Unfortunately, free CI runners are not as capable as I had hoped. I've split the jobs now, but dunno if this will be acceptable. |
yes, we prefer multiple free runner compared to 1 large runner 👍 @bors try |
{aarch64,x86_64}-*-windows-gnullvm: build host tools This will require MCP, but I suppose we need to know how long it takes to build first. I opted for bootstrapping from Linux because that's the easiest host system to work with, but once this hits beta, having dedicated Windows runners would be sensible and probably preferable. `--enable-full-tools` for whatever reason doesn't seem to work when cross-compiling, because LLVM tools for the new hosts are not copied into the expected directory. And WiX that bootstrap relies upon to create .msi installers only supports Windows. I haven't tried, but it might be usable via Wine. Almost every commit is self-contained, so let me know if I should split them into separate PRs. try-job: dist-aarch64-windows-gnullvm try-job: dist-x86_64-windows-gnullvm
This comment has been minimized.
This comment has been minimized.
💔 Test failed - checks-actions |
@bors try |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
r=me on the docs after fixing it
@@ -147,8 +149,7 @@ target | std | notes | |||
[`aarch64-apple-ios-macabi`](platform-support/apple-ios-macabi.md) | ✓ | Mac Catalyst on ARM64 | |||
[`aarch64-apple-ios-sim`](platform-support/apple-ios.md) | ✓ | Apple iOS Simulator on ARM64 | |||
[`aarch64-linux-android`](platform-support/android.md) | ✓ | ARM64 Android | |||
[`aarch64-pc-windows-gnullvm`](platform-support/windows-gnullvm.md) | ✓ | ARM64 MinGW (Windows 10+), LLVM ABI | |||
[`aarch64-unknown-fuchsia`](platform-support/fuchsia.md) | ✓ | ARM64 Fuchsia | |||
`aarch64-unknown-fuchsia`](platform-support/fuchsia.md) | ✓ | ARM64 Fuchsia |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you broke the [
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oof, good catch. Just when I thought my switch from Vim style bindings to Helix style is going well...
@bors r=marcoieni,Noratrieb |
…Noratrieb {aarch64,x86_64}-pc-windows-gnullvm: build host tools This is a temporary single-release workflow to create stage0 for these targets. I opted for bootstrapping from Linux because that's the easiest host system to work with, but once this hits beta, having dedicated Windows runners would be sensible and probably preferable. `--enable-full-tools` for whatever reason doesn't seem to work when cross-compiling, because LLVM tools for the new hosts are not copied into the expected directory. rust-lang/compiler-team#877
Rollup of 10 pull requests Successful merges: - #135656 (Add `-Z hint-mostly-unused` to tell rustc that most of a crate will go unused) - #138237 (Get rid of `EscapeDebugInner`.) - #140772 ({aarch64,x86_64}-pc-windows-gnullvm: build host tools) - #140774 (Affirm `-Cforce-frame-pointers=off` does not override) - #141610 (Stabilize `feature(generic_arg_infer)`) - #141864 (Handle win32 separator for cygwin paths) - #142384 (Bringing `rustc_rayon_core` in tree as `rustc_thread_pool`) - #142502 (rustdoc_json: improve handling of generic args) - #142571 (Reason about borrowed classes in CopyProp.) - #142591 (Add spawn APIs for BootstrapCommand to support deferred command execution) r? `@ghost` `@rustbot` modify labels: rollup
@bors r- #142656 (comment) The removed SH file is being used from somewhere. |
Sorry, I forgot about to revert the Dockerfile change that was made by nobody else but me basically a year ago... Should be fine now. |
@bors2 try jobs=dist-various-1 |
{aarch64,x86_64}-pc-windows-gnullvm: build host tools This is a temporary single-release workflow to create stage0 for these targets. I opted for bootstrapping from Linux because that's the easiest host system to work with, but once this hits beta, having dedicated Windows runners would be sensible and probably preferable. `--enable-full-tools` for whatever reason doesn't seem to work when cross-compiling, because LLVM tools for the new hosts are not copied into the expected directory. rust-lang/compiler-team#877 try-job: dist-various-1
Thanks! @bors r+ rollup=iffy |
☀️ Test successful - checks-actions |
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing 044514e (parent) -> d1d8e38 (this PR) Test differencesNo test diffs found Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard d1d8e386c5e84c4ba857f56c3291f73c27e2d62a --output-dir test-dashboard And then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
Finished benchmarking commit (d1d8e38): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results (primary -2.5%, secondary 0.4%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary -0.2%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 693.624s -> 692.944s (-0.10%) |
This is a temporary single-release workflow to create stage0 for these targets.
I opted for bootstrapping from Linux because that's the easiest host system to work with, but once this hits beta, having dedicated Windows runners would be sensible and probably preferable.
--enable-full-tools
for whatever reason doesn't seem to work when cross-compiling, because LLVM tools for the new hosts are not copied into the expected directory.rust-lang/compiler-team#877